home *** CD-ROM | disk | FTP | other *** search
/ QRZ! Ham Radio 4 / QRZ Ham Radio Callsign Database - Volume 4.iso / digests / tcp / 940104.txt < prev    next >
Internet Message Format  |  1994-11-13  |  9KB
  1. Date: Mon, 30 May 94 04:30:02 PDT
  2. From: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  3. Errors-To: TCP-Group-Errors@UCSD.Edu
  4. Reply-To: TCP-Group@UCSD.Edu
  5. Precedence: Bulk
  6. Subject: TCP-Group Digest V94 #104
  7. To: tcp-group-digest
  8.  
  9.  
  10. TCP-Group Digest            Mon, 30 May 94       Volume 94 : Issue  104
  11.  
  12. Today's Topics:
  13.                               Gracillis
  14.                              Mail failure
  15.                       More RSPF Help needed.....
  16.                       TCP-Group Digest V94 #103
  17.                                 unsub
  18.  
  19. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>.
  20. Subscription requests to <TCP-Group-REQUEST@UCSD.Edu>.
  21. Problems you can't solve otherwise to brian@ucsd.edu.
  22.  
  23. Archives of past issues of the TCP-Group Digest are available
  24. (by FTP only) from UCSD.Edu in directory "mailarchives".
  25.  
  26. We trust that readers are intelligent enough to realize that all text
  27. herein consists of personal comments and does not represent the official
  28. policies or positions of any party.  Your mileage may vary.  So there.
  29. ----------------------------------------------------------------------
  30.  
  31. Date: Sat, 28 May 94 10:41:37 CDT
  32. From: route66@ddl.chi.il.us (System Administrator)
  33. Subject: Gracillis
  34. To: tcp-group@ucsd.edu
  35.  
  36. I have been looking into buying Gracillis for 9600 baud packet. Has 
  37. anyone ever tried it..and if so, how is it on TCP/IP?
  38. Also, I'd rather not spend $1,000 for Gracillis new..by chance does 
  39. anyone out there have a used one setup they wanna get rid of?
  40.  
  41. Thanks,
  42. Greg Kaiser - N9TOL
  43.  
  44. ------------------------------
  45.  
  46. Date: 29 May 1994 09:04:09 EST
  47. From: "POSTMASTER" <HARRIS.POSTMAS8@IC1D.HARRIS.COM>
  48. Subject: Mail failure
  49. To: TCP-Group@UCSD.EDU
  50.  
  51. Date: Sat, 28 May 94 04:56:05 CST
  52. From: Jack Snodgrass                    <kf5mg@kf5mg.ampr.org>
  53. Subject: More RSPF Help needed.....
  54. To: tcp-group mailling list             <tcp-group@UCSD.EDU>
  55.  
  56.     We've been tearing out my hair trying to figure out how to link 2 RSPF
  57. routers that use an IP Router to communicate.  It seems like RSPF should
  58. work and NOT require that every station in the network Run RSPF, but we
  59. just can't figure out how to make it work.
  60.  
  61.     We've got:
  62.  
  63.     --------            --------            --------
  64.      kf5mg   <---440---> wb5tey <---144--->   k5rw
  65.     --------            --------            --------
  66.  
  67.     kf5mg and k5rw are running RSPF. When either one sends out it's RSPF
  68. broadcast, the other station can't hear it because they're on separate
  69. networks. Is there an easy way to fix this?
  70.  
  71.     We've set up and AXIP link between the two RSPF routers and set up the
  72. routes between k5rw and kf5mg to use wb5tey.  Now they can hear each others
  73. RSPF broadcast, but the RSPF added routes are screwed up.  All of k5rw's
  74. RSPF added routes on kf5mg show that they route through k5rw on 440 instead
  75. of wb5tey.  All of kf5mg's RSPF added routes on k5rw show that they route
  76. through kf5mg on 144 instead of wb5tey.  I'm guessing that the reason the
  77. routes are screwed up is that RSPF assumes that since it can 'hear' the
  78. station direct ( because of the axip link ) the RSPF added routes assume
  79. that they go direct to the remote system and don't take into account any
  80. pre-existing routes set up between the two RSPF routers.
  81.  
  82.     Next, we set up an ENCAP link in hopes that if the AXIP link was run
  83. over the ENCAP link the RSPF added links would use the ENCAP link routes.
  84. That didn't work either. The AXIP stuff goes over the ENCAP route, but
  85. the RSPF added routes still ignore the IP router that's in between the two
  86. RSPF routers.
  87.  
  88.     Someone is probably going to suggest that wb5tey ( in our example ) run
  89. RSPF. Yes... that will work, but I want/need to figure out this problem.
  90. Once we get this working, we'll add RSPF to both of our Internet Gateways.
  91. There's no way to get the network routers between the two gateways to run
  92. RSPF.
  93.  
  94.     Anyway.... either there is something basic that I'm missing or RSPF is
  95. really un-usable in a standard network and I can't see how one can really
  96. be using it. Any info/help/suggestions ( preferably working ) would be
  97. appreciated. Thanks.
  98.  
  99. 73's  de  Jack  -  kf5mg
  100. Internet        -  kf5mg@kf5mg.ampr.org            -  44.28.0.14
  101. AX25net         -  kf5mg@kf5mg.#dfw.tx.usa.noam    -  home (817) 488-4386
  102. Dialup          -  kf5mg@tcet.unt.edu              -  work (looking  for)
  103. ==============================================================================
  104. =
  105. ===           Buffalo's new area code.... 044.... "Deal with it"            ==
  106. =
  107. ==============================================================================
  108. =
  109.  
  110. ------------------------------
  111.  
  112. Date: Sat, 28 May 1994 16:28:01 -0400
  113. From: goldstein@carafe.tay2.dec.com
  114. Subject: More RSPF Help needed.....
  115. To: tcp-group@ucsd.edu
  116.  
  117. Jack,
  118.  
  119. >    We've got:
  120. >
  121. >    --------            --------            --------
  122. >     kf5mg   <---440---> wb5tey <---144--->   k5rw
  123. >    --------            --------            --------
  124. >
  125. >    kf5mg and k5rw are running RSPF. When either one sends out it's RSPF
  126. >broadcast, the other station can't hear it because they're on separate
  127. >networks. Is there an easy way to fix this?
  128.  
  129. Not an easy way...
  130.  
  131. This would have been solved fairly easily had RSPF2.2 been implemented.
  132. RSPF2.2 is a spec that makes clear that "normal" IP rules of "subnets"
  133. do NOT apply, and therefore you can create adjacencies using any kind
  134. of lower-layer (subnetwork in the OSIRM sense) connection and RSPF will
  135. use them if appropriate.  But the code in NOS does not override IP's
  136. routing function, and treats RSPF node groups as IP subnets, which
  137. they ain't.  I don't know what hackery has been done recently to allow
  138. faking things, but it's all half-way.
  139.  
  140. Note that RSPF was designed to run on routers, but not be needed on
  141. end stations.  Your example is of course the opposite, and tries to
  142. use intellgent end systems to get past a lack of intelligent routers.
  143. Perfectly sensible but since I don't personally _use_ any of the RSPF
  144. variants currently implemented, I can't tell you what works.
  145.  
  146. If somebody would take the 2.2 spec and really implement it... Naaah,
  147. we're hams.  Why do it right when a quick and dirty early hack is
  148. available?  Why should routing be different from the "202" modems?  :-(
  149.  
  150. (sig)>           Buffalo's new area code.... 044.... "Deal with it"
  151. I must be missing something...
  152.     fred k1io
  153.  
  154. ------------------------------
  155.  
  156. Date: Sat, 28 May 94 11:21:03 CST
  157. From: fchavarr@udgserv.cencar.udg.mx (Fco. J. Chavarria -POLITEC)
  158. To: tcp-group@UCSD.EDU
  159.  
  160. unsub fchavarr@udgserv.cencar.udg.mx
  161.  
  162. ------------------------------
  163.  
  164. End of TCP-Group Digest V94 #103
  165. ******************************
  166.  
  167.  
  168. ------------------------------------------------------------------------------
  169.  
  170. ------------------------------
  171.  
  172. Date: Sun, 29 May 94 05:48:00 -0000
  173. From: mikebw@bilow.bilow.uu.ids.net (Mike Bilow)
  174. Subject: More RSPF Help needed.....
  175. To: tcp-group@UCSD.EDU
  176.  
  177. Cc: kf5mg@kf5mg.ampr.org
  178.  
  179.  JS>     We've been tearing out my hair trying to figure out 
  180.  JS> how to link 2 RSPF 
  181.  JS> routers that use an IP Router to communicate.  It seems like RSPF should 
  182.  JS> work and NOT require that every station in the network Run RSPF, but we 
  183.  JS> just can't figure out how to make it work.  
  184.  
  185. I understand your problem exactly.  There really are no easy ways to do what
  186. your want, but it should be possible.  However, it is an involved thing and I
  187. don't want to sit here typing away nonsense before I think it through.  A lot
  188. of these kinds of problems are a result of features in the formal RSPF spec
  189. remaining unimplemented.
  190.  
  191. RSPF was intended to function as an interior routing protocol within the
  192. autonomous system which is Amprnet.  The expectation was that all routers would
  193. be running the routing protocol.  This is not an unreasonable expectation, and
  194. it applies pretty much equally to any other routing protocol besides RSPF.  End
  195. nodes which have no routing responsibility are not usually expected to run
  196. RSPF, but that is a very different thing.
  197.  
  198. -- Mike
  199.  
  200. ------------------------------
  201.  
  202. Date: Mon, 30 May 1994 09:05:19 CET
  203. From: "Jack Stiekema" <JACK@vic1.victron.nl>
  204. Subject: TCP-Group Digest V94 #103
  205. To: Advanced Amateur Radio Networking Group <tcp-group@ucsd.edu>
  206.  
  207. >>    We've been tearing out my hair trying to figure out how to link 2 RSPF
  208. >>routers that use an IP Router to communicate.  It seems like RSPF should
  209.  
  210. Maybe a silly question,
  211. but what is RSPF?
  212.  
  213.  
  214. Kind regards,
  215. Jack Stiekema
  216. Product Manager Connectivity
  217. +----------------------------------------------------+
  218. | Victron bv   POB 31   9700 AA Groningen   Holland  |
  219. |   Phone: +31 50 446222   Fax: +31 50 424107        |
  220. |   Email: jack@victron.nl Internet: 193.78.6.6      |
  221. |   Home:  +31 5980 80498  pe0mot@pe0mot.ampr.org    |
  222. +----------------------------------------------------+
  223.  
  224. ------------------------------
  225.  
  226. Date: Mon, 30 May 1994 10:43:38 MET
  227. From: betaille@lurvax.lure.ups.circe.fr
  228. Subject: unsub
  229. To: tcp-group@ucsd.edu
  230.  
  231. unsub betaille@lure.ups.circe.fr tcp-group
  232.  
  233. ------------------------------
  234.  
  235. End of TCP-Group Digest V94 #104
  236. ******************************
  237.